9장 클로드의 생각 깊이 조절하기 (입문판)

출처: 클로드 코드 완벽 가이드, 코드팩토리 최지호

이 장에서 딱 4가지만: 1. 클로드한테 "과정을 보여줘"라고 하면 답이 좋아진다 (CoT) 2. "생각해라", "단계별로"라는 말만 넣어도 그게 된다 3. <thinking>, <answer> 태그로 생각과 답을 깔끔히 나눌 수 있다 4. "고민해라"라고 하면 클로드가 더 오래·더 깊이 생각한다 (확장된 사고)

이 장의 학습 목표

이 장을 끝내면 여러분은 - CoT(생각의 사슬)가 무엇이고 왜 답을 좋게 만드는지 설명한다. - "생각해라" 같은 말로 CoT를 유도하는 법을 따라 한다. - <thinking>과 <answer> 태그로 생각과 답을 구분한다. - "고민해라 / 깊게 고민해라 / 더 깊게 고민해라"의 차이를 구분한다.

1. 답만 받았더니 좀 허전했던 적, 있죠? (CoT의 이해)

이거 이렇게 하다 막힌 적 있죠?

클로드한테 "REST API 설계해줘"라고 했더니 짠 하고 결과만 툭 나옵니다.

그런데 막상 보니 뭔가 빠진 것 같습니다. "왜 이렇게 설계했지?"를 물어볼 수가 없어요. 과정이 안 보이니까요.

마치 수학 시험에서 풀이 없이 답만 적은 것과 같습니다. 답이 틀리면 어디서 틀렸는지 알 길이 없죠.

그게 바로 CoT가 필요한 순간입니다.

그래서 CoT가 뭐냐면

CoT(Chain of Thought, 생각의 사슬)는 클로드한테 "결론부터 말하지 말고, 과정을 차근차근 보여줘"라고 부탁하는 방법입니다.

새 용어 한 줄 뜻: CoT란 "답을 내기 전에 생각 과정을 단계별로 적게 하는 것". 일상 비유로는 '수학 시험에서 풀이 과정을 같이 적는 것'.

말 그대로 생각을 사슬처럼 한 칸 한 칸 이어가게 만드는 거예요.

비유로 먼저, 그다음 연결

수학 시험을 떠올려 보세요. 답만 적으면 부분 점수를 못 받습니다. 하지만 풀이 과정을 적으면 어디서 틀렸는지 보이고, 선생님도 확인할 수 있죠.

클로드도 똑같습니다.

CoT를 쓰면 좋은 점 3가지

CoT를 쓰면 답이 이렇게 좋아집니다.

1. 정확해집니다 (정확성) 수학, 논리, 복합 분석처럼 여러 단계가 필요한 일에서 각 단계를 짚고 넘어가니 실수가 확 줄어요.

2. 짜임새가 좋아집니다 (일관성) 결과물이 더 긴밀하고 체계적으로 정리됩니다.

3. 고치기 쉬워집니다 (디버깅 용이성) 생각의 흐름이 다 보이니까 "아, 3단계에서 잘못 짚었네" 하고 바로 찾아 고칠 수 있어요.

새 용어 한 줄 뜻: 디버깅이란 "잘못된 부분을 찾아 고치는 것". 일상 비유로는 '시험지에서 틀린 줄을 빨간 펜으로 짚어내는 것'.

예시 2개로 확인

예시 ① 일상 비유로 선생님이 학생한테 "답만 말해봐"라고 하면 답만 나옵니다. "풀이 과정을 보여줘"라고 하면 과정을 하나하나 적어주죠. 클로드도 부탁하는 말에 따라 이렇게 달라집니다.

예시 ② 실제로는 이렇게

단계별로 생각해서 REST API를 설계해줘.

이렇게 "단계별로 생각해서"만 붙여도 클로드가 1단계, 2단계로 나눠 답하기 시작합니다.

한 걸음 더 ▸ 항상 CoT를 써야 하는 건 아니다

CoT가 만능은 아닙니다. 답이 빨리 나와야 하거나, 일이 아주 단순하면 오히려 과정을 늘어놓는 게 비효율적이에요.

예를 들어 "이 파일 이름이 뭐야?" 같은 간단한 질문에 굳이 단계별 사고를 시킬 필요는 없습니다.

속도가 중요하면 그냥 묻고, 정확함이 중요하면 CoT를 쓰세요. 이게 속도와 성능 사이의 균형입니다.

잘못된 예 vs 올바른 예

잘못된 예 (단순한 일에 무겁게)

1 더하기 1이 뭔지 단계별로 깊이 생각해서 답해줘.

→ 간단한 산수에 생각 과정을 길게 늘어놓아 시간만 낭비.

올바른 예 (복잡한 일에 제대로)

이 결제 모듈의 보안 취약점을 단계별로 생각해서 찾아줘.

→ 여러 단계 점검이 필요한 일이라 CoT가 진짜 도움이 됨.

이럴 때 이렇게: "이게 한 번에 답할 수 있는 간단한 질문인가?"를 먼저 떠올리고, 아니라면 CoT를 붙이세요.

2. "생각해라" 한마디면 됩니다 (CoT 유도하기)

이거 이렇게 하다 막힌 적 있죠?

"CoT 좋다는 건 알겠는데, 그걸 어떻게 켜는 거지?" 설정 메뉴를 찾아 헤맨 적 있나요?

사실 설정 같은 건 없습니다. 그냥 말로 부탁하면 끝이에요.

그게 바로 CoT 유도입니다.

그래서 어떻게 하냐면

프롬프트에 이런 말만 넣으면 됩니다. - "생각해라" - "단계별로 설명해줘" - "차근차근 풀어줘"

새 용어 한 줄 뜻: 프롬프트란 "클로드한테 시키는 말, 즉 지시문". 일상 비유로는 '주문서에 적는 요청 사항'.

이 한마디로 클로드가 결론만 말하던 걸 멈추고 과정을 펼쳐 보이기 시작합니다.

비유로 먼저, 그다음 연결

학생한테 "답만 말해봐"라고 하면 답만 나오고, "풀이 과정을 보여줘"라고 하면 과정을 적어줍니다. 부탁하는 말 한마디 차이죠.

예시 2개로 확인

예시 ① 잘못된 예 vs 올바른 예 (before/after)

before (그냥 요청)

단순히 REST API를 어떻게 설계할 수 있는지 단계별로 생각하고 답변해줘.

→ 단계별로 답은 하지만, 생각이 자세하지 않고 어디까지가 생각이고 어디부터가 답인지 헷갈립니다.

after (구조까지 부탁)

REST API를 구축하려면 어떻게 해야 해?
생각 과정을 <thinking> 태그에 입력해주고,
그를 기반으로 <answer> 태그에 답변을 입력해줘.

→ 생각과 답이 또렷하게 나뉩니다. (태그 이야기는 다음 섹션)

예시 ② 미니 시나리오 함수 하나를 리팩터링하고 싶은데 막막할 때

이 함수를 어떻게 정리하면 좋을지 단계별로 생각해서 알려줘.

이럴 때 이렇게: 막막한 작업일수록 "단계별로 생각해서"를 앞에 붙이면 클로드가 작업을 잘게 쪼개 안내해 줍니다.

3. 생각과 답을 칸막이로 나누기 (XML 태그)

이거 이렇게 하다 막힌 적 있죠?

클로드가 단계별로 답해주긴 하는데, 생각이랑 진짜 답변이 한 덩어리로 섞여 있어 "결국 결론이 뭐야?"를 찾느라 스크롤만 한 적 있죠?

그게 바로 칸막이가 필요한 순간입니다.

그래서 어떻게 하냐면

<thinking>과 <answer>라는 태그로 생각 칸과 답 칸을 나눠달라고 부탁하면 됩니다.

새 용어 한 줄 뜻: XML 태그란 "<이름>내용</이름> 모양으로 내용을 감싸 구역을 표시하는 표식". 일상 비유로는 '서랍에 붙이는 라벨'. (자세한 모양은 0장 용어집 참고)

<thinking>은 생각을 담는 서랍, <answer>는 최종 답을 담는 서랍이라고 보면 됩니다.

비유로 먼저, 그다음 연결

책상 위에 서류가 뒤죽박죽이면 원하는 걸 못 찾죠. "메모는 왼쪽 서랍, 완성본은 오른쪽 서랍"으로 나누면 한눈에 찾을 수 있습니다.

예시 2개로 확인

예시 ① 실제 프롬프트

생각 과정을 <thinking> 태그에,
답변을 <answer> 태그에 입력해줘.

이렇게 부탁하면 클로드가 아래처럼 나눠서 답합니다.

<thinking>
REST API 구축 질문이다. 이런 순서로 설명하면 좋겠다.
1. REST API의 개념과 원칙
2. 기술 스택 선택
3. API 설계 과정
</thinking>

<answer>
REST API 구축 방법을 단계별로 설명드리겠습니다.
1. 기본 개념: 자원은 URI로 식별, 행위는 GET/POST/PUT/DELETE, 표현은 JSON 등
2. 기술 스택: Node.js의 Express, Python의 FastAPI 등
</answer>

생각은 윗칸, 답은 아랫칸. 깔끔하죠.

예시 ② 미니 시나리오 긴 답을 받았는데 결론만 빨리 보고 싶을 때 "생각은 <thinking>에, 결론은 <answer>에 적어줘"라고 하면 다음부터는 <answer> 칸만 읽으면 됩니다.

한 걸음 더 ▸ 플래닝 모드에서는 색으로 나뉜다

클로드 코드에는 플래닝 모드가 있습니다.

새 용어 한 줄 뜻: 플래닝 모드란 "클로드가 바로 실행하지 않고 먼저 계획을 보여주는 모드". 일상 비유로는 '요리 전에 레시피부터 읽어주는 것'.

이 모드에서는 XML 태그를 써달라고 해도 태그를 생략하고 답할 때가 있습니다. 대신 생각은 계획 위에 회색 글씨로 표시돼서, 태그가 없어도 생각과 답을 한눈에 구분할 수 있어요.

그러니 플래닝 모드에서 태그가 안 보여도 당황하지 마세요. 회색 = 생각, 보통 글씨 = 답, 이렇게 기억하면 됩니다.

4. "고민해봐"라고 하면 더 깊이 생각해요 (확장된 사고)

이거 이렇게 하다 막힌 적 있죠?

"테스트 코드 작성해줘"라고 했더니 기본적인 것만 딱 만들어 줍니다. 빈 값이 들어오거나, 숫자가 너무 클 때 같은 까다로운 경우는 쏙 빠져 있어요.

좀 더 꼼꼼하게 시키고 싶은데... 그게 바로 확장된 사고가 필요한 순간입니다.

그래서 확장된 사고가 뭐냐면

확장된 사고(Extended Thinking)는 클로드한테 "시간을 더 줄게, 깊이 생각해봐"라고 하는 기능입니다.

새 용어 한 줄 뜻: 확장된 사고란 "클로드가 평소보다 더 오래·더 깊이 생각하도록 여유를 주는 기능". 일상 비유로는 '시험 시간을 10분에서 2시간으로 늘려주는 것'.

이때 클로드한테 주는 '생각할 여유'를 사고 예산이라고 부릅니다.

새 용어 한 줄 뜻: 사고 예산(Thinking Budget)이란 "클로드가 생각하는 데 쓸 수 있는 분량". 일상 비유로는 '시험에서 주어진 시간'. 예산이 클수록 더 깊이 고민한다.

비유로 먼저, 그다음 연결

수학 시험에서 10분만 주면 쉬운 문제만 풉니다. 2시간을 주면 어려운 응용문제도 충분히 고민해서 풀 수 있죠.

확장된 사고는 클로드한테 그 '2시간'을 주는 셈입니다.

깊이를 3단계로 조절할 수 있어요

말만 살짝 바꾸면 생각 깊이가 달라집니다.

1단계 — "고민해라" (Think) 기본적인 확장된 사고입니다. 예: "이 프로젝트를 분석하고 고민한 다음 테스트 코드를 작성해줘"

2단계 — "깊게 고민해라" (Think Hard) 더 오래 생각하게 만듭니다. 예: "깊게 고민해서 이 함수 테스트의 엣지 케이스를 추가해줘"

새 용어 한 줄 뜻: 엣지 케이스란 "보통은 잘 안 일어나지만 가끔 터지는 까다로운 경우". 일상 비유로는 '자판기에서 동전이 아니라 단추를 넣었을 때'.

3단계 — "더 깊게 고민해라" (Think Harder) 가장 깊이 생각하게 만듭니다. 예: "다루지 않은 에지 케이스에 대해 더욱 깊게 고민해줘"

단계가 올라갈수록 사고 예산이 더 많이 주어져 더 다양한 경우까지 살펴봅니다.

예시 2개로 확인

예시 ① 잘못된 예 vs 올바른 예 (before/after)

before (확장된 사고 없이)

이 프로젝트에 테스트 코드를 작성해줘.

→ 기본 테스트만 생성. 까다로운 경우는 누락될 수 있음.

after (확장된 사고 활용)

이 프로젝트를 충분히 분석하고 고민한 다음 테스트 코드를 작성해줘.

→ 구조를 먼저 파악하고 여러 상황을 따져 테스트를 만듦.

한 단계 더 (더 깊게)

다루지 않은 에지 케이스에 대해 더욱 깊게 고민해줘.

→ 경계값, 예외 상황, 동시에 여러 요청이 들어오는 문제까지 살핌.

예시 ② 미니 시나리오 — 보안 점검 배포 전에 보안이 걱정될 때

이 프로젝트에 필요한 보안 작업을 깊게 고민해서 정리해줘.

이럴 때 이렇게: 실수하면 큰일 나는 작업(보안, 결제, 데이터 삭제)일수록 "깊게 고민해서"를 붙여 클로드를 더 신중하게 만드세요.

한 걸음 더 ▸ 한국어 프롬프트 팁

한국어로 시킬 때 생각 수준을 더 확실히 정하고 싶다면, 프롬프트 맨 앞에 영어 키워드를 붙이는 방법이 있습니다.

Think: 이 프로젝트에 필요한 보안 작업을 고민해줘
Think hard: 이 함수 테스트의 엣지 케이스들을 추가해줘

이렇게 Think:, Think hard:를 앞에 적으면 원하는 생각 깊이를 더 또렷하게 전달할 수 있습니다.

한 걸음 더 ▸ 책 속 실제 예제 (암호화폐 대시보드)

책에서는 실제 프로젝트로 확장된 사고를 보여줍니다. - 프로젝트: 암호화폐 순위를 보여주는 대시보드 - 화면 도구: Next.js와 React로 만듦 - 로그인: Supabase Auth를 쓸 예정 - 화면 글자: 한국어로 번역됨

위 도구·버전 이름은 원서/노트 기준 예시이며, 최신 값은 공식 문서(클로드 코드 공식 문서)에서 확인하세요.

여기서 "REST API를 설계해줘"를 확장된 사고로 부탁하니 클로드가 이렇게 생각을 펼쳤습니다. 1. 암호화폐 데이터와 관련된 API 목록 뽑기 2. 사용자와 관련된 API 설계하기 3. 데이터베이스 구조 설계하기 (프로필, 포트폴리오, 관심목록 등)

복잡한 설계일수록 확장된 사고가 빛을 발하는 예입니다.

5. CoT와 확장된 사고, 뭐가 다를까

둘 다 "생각을 더 시키는" 방법이라 헷갈릴 수 있어요. 간단히 표로 정리합니다.

확장된 사고의 3단계도 다시 한번 정리하면

참고: 위에서 다룬 기능·키워드의 동작 방식이나 한도는 클로드 코드 버전에 따라 달라질 수 있습니다. 정확한 최신 정보는 공식 문서(클로드 코드 공식 문서)에서 확인하세요.

직접 해보기 (연습문제)

문제 1 (기본) CoT(생각의 사슬)를 가장 잘 설명한 것은? - A) 클로드의 학습 데이터를 늘리는 기법 - B) 클로드가 답을 내기 전에 단계별 생각 과정을 보여주게 하는 기법 - C) 클로드의 응답 속도를 높이는 기법 - D) 클로드 모델 설정을 바꾸는 기법

정답: B CoT는 최종 답 전에 생각 과정을 단계별로 적게 하는 기법입니다. 수학 시험에서 풀이 과정을 적는 것과 같아요.

문제 2 (기본) 다음 두 부탁의 차이를 한 줄로 설명하세요. - A: "REST API를 설계해줘" - B: "REST API를 설계해줘. 생각은 <thinking>에, 답은 <answer>에 적어줘"

정답 예시: A는 생각과 답이 섞여 나오고, B는 태그로 생각 칸과 답 칸이 나뉘어 결론을 찾기 쉽습니다.

문제 3 (중급) 테스트 코드를 만들 때 "고민해라 / 깊게 고민해라 / 더 깊게 고민해라"의 차이를 설명하세요.

정답 예시: - 고민해라(Think): 기본적인 단위 테스트를 만든다. - 깊게 고민해라(Think Hard): 빈 값, 경계값 같은 엣지 케이스까지 넣는다. - 더 깊게 고민해라(Think Harder): 동시 요청, 시간 초과 같은 극단 상황까지 살핀다. 단계가 올라갈수록 사고 예산이 늘어 더 다양한 경우를 본다.

핵심 정리

• 답만 받으면 검토가 어렵다. "생각해라", "단계별로"라고 부탁하면 과정이 보인다 → CoT.
• CoT의 이점 3가지: 정확성, 일관성, 고치기 쉬움(디버깅).
• 단순한 일엔 CoT가 오히려 비효율적. 속도와 성능의 균형을 보자.
• <thinking>과 <answer> 태그로 생각 칸과 답 칸을 나누면 결론을 찾기 쉽다.
• 플래닝 모드에서는 태그 없이 회색 글씨로 생각이 구분된다.
• "고민해라"로 확장된 사고를 켜면 클로드가 사고 예산을 받아 더 깊이 생각한다.
• 깊이는 3단계: 고민해라 → 깊게 고민해라 → 더 깊게 고민해라.
• 복잡한 설계, 엣지 케이스, 보안처럼 신중함이 필요한 일에 확장된 사고가 효과적이다.

다음 장 예고: 다음 장에서는 또 다른 클로드 코드 활용법을 다룹니다. 지금 그 내용을 몰라도 이 장을 따라오는 데 전혀 지장 없습니다.